With the introduction of pausable portals, the comment for `limitedCommandResult`
needs to be updated to reflect the current behavior.

Release note: None

This change introduces a new session variable for a preview feature. When set to `true`,
all non-internal portals with read-only [`SELECT`](../v23.1/selection-queries.html)
queries without sub-queries or post-queries can be paused and resumed in an interleaving
manner, but are executed with a local plan.

Release note (SQL change): Added the session variable `multiple_active_portals_enabled`.
This setting is only for a preview feature. When set to `true`, it allows
multiple portals to be open at the same time, with their execution interleaved
with each other. In other words, these portals can be paused. The underlying
statement for a pausable portal must be a read-only `SELECT` query without
sub-queries or post-queries, and such a portal is always executed with a local
plan.

…e persistence

This commit is part of the implementation of multiple active portals. In order to
execute portals interleavingly, certain resources need to be persisted and their
clean-up must be delayed until the portal is closed. Additionally, these resources
don't need to be re-setup when the portal is re-executed.

To achieve this, we store the cleanup steps in the `cleanup` function stacks in
`portalPauseInfo`, and they are called when any of the following events occur:

1. SQL transaction is committed or rolled back
2. Connection executor is closed
3. An error is encountered when executing the portal
4. The portal is explicited closed by the user

The cleanup functions should be called in the original order of a normal portal.
Since a portal's execution follows the `execPortal() -> execStmtInOpenState() ->
dispatchToExecutionEngine() -> flow.Run()` function flow, we categorize the cleanup
functions into 4 "layers", which are stored accordingly in `PreparedPortal.pauseInfo`.
The cleanup is always LIFO, following the

- resumableFlow.cleanup
- dispatchToExecutionEngine.cleanup
- execStmtInOpenState.cleanup
- exhaustPortal.cleanup`

order. Additionally, if an error occurs in any layer, we clean up the current and
proceeding layers. For example, if an error occurs in `execStmtInOpenState()`, we
perform `resumableFlow.cleanup` and `dispatchToExecutionEngine.cleanup` (proceeding)
and then `execStmtInOpenState.cleanup` (current) before returning the error to
`execPortal()`, where `exhaustPortal.cleanup` will eventually be called. This is to
maintain the previous clean-up process for portals as much as possible.

We also pass the `PreparedPortal` as a reference to the planner in
`execStmtInOpenState()`,so that the portal's flow can be set and reused.

Release note: None

When executing or cleaning up a pausable portal, we may encounter an error and
need to run the corresponding clean-up steps, where we need to check the latest
`retErr` and `retPayload` rather than the ones evaluated when creating the
cleanup functions.

To address this, we use portal.pauseInfo.retErr and .retPayload to record the
latest error and payload. They need to be updated for each execution.

Specifically,

1. If the error happens during portal execution, we ensure `portal.pauseInfo`
records the error by adding the following code to the main body of
`execStmtInOpenState()`:

``` go
defer func() {
	updateRetErrAndPayload(retErr, retPayload)
}()
```

Note this defer should always happen _after_ the defer of running the cleanups.

2. If the error occurs during a certain cleanup step for the pausable portal,
we ensure that cleanup steps after it can see the error by always having
`updateRetErrAndPayload(retErr, retPayload)` run at the end of each cleanup step.

Release note: None

This commit adds several restrictions to pausable portals to ensure that they
work properly with the current changes to the consumer-receiver model.
Specifically, pausable portals must meet the following criteria:

1. Not be internal queries
2. Be read-only queries
3. Not contain sub-queries or post-queries
4. Only use local plans

These restrictions are necessary because the current changes to the
consumer-receiver model only consider the local push-based case.

Release note: None

When resuming a portal, we always reset the planner. However we still need the
planner to respect the outer txn's situation, as we did in cockroachdb#98120.

Release note: None

Release note: None

We now only support multiple active portals with local plan, so explicitly
disable it for this test for now.

Release note: None